6.2. Client Considerations
Outlook versions earlier than Outlook 2003 are not supported with Exchange Server 2010 mailboxes. As outlined in the Section 3.5 section of this article, if Outlook 2003 is in use, one of the primary considerations for planning mailbox moves is that RPC connectivity for MAPI clients requires RPC encryption by default in Exchange Server 2010.
6.3. Recipient Update Service Migration
In addition to
considering the Outlook version or versions deployed in the environment,
you need to consider how recipients are provisioned in Exchange Server
2010 compared to Exchange Server 2003 as well as how e-mail address
policies are applied.
6.3.1. RUS and Exchange Server 2003
The Recipient
Update Service (RUS) was introduced in Exchange Server 2000 and used in
Exchange Server 2003 as well. Its job was to locate and complete the
provisioning process for newly created recipient objects in Active
Directory by creating Exchange-specific attribute values on the objects.
The RUS was also responsible for updating existing objects by modifying
the Active Directory's object's appropriate attributes. The two types
of the RUS in an Exchange Server 2003 organization are the Enterprise
Configuration Recipient
Update Service (one instance per Exchange Server 2003 organization) and
the domain Recipient Update Service. As its name implies, there is one
instance of the domain RUS for each domain that contains mail or
mailbox-enabled users.
When you created an Exchange Server 2003 mail or mailbox-enabled user or mail-enabled group using the Active
Directory Users and Computers (ADUC) console, a few key attributes were
set immediately when the object was created. These attributes allowed
the RUS to discover the object and complete the provisioning process by
backfilling the remaining Exchange-specific attributes asynchronously.
6.3.2. Recipient Creation in Exchange Server 2010
In Exchange Server 2007 and
higher, including Exchange Server 2010, recipient objects are now fully
provisioned as they are created in the EMS or the EMC GUI; the RUS
background process to discover and update objects has been removed. This
means that mailboxes can be used immediately after being created in
Exchange Server 2010; with the RUS, the asynchronous process had to
stamp the user object before the recipient or mailbox was usable. This
meant that if problems arose they could be complicated to troubleshoot;
the RUS was an asynchronous process and it could be difficult to
determine whether it wasn't working or was just delayed.
Another role of the RUS was to
apply recipient policies in Exchange 2000 Server and Exchange Server
2003, and to update recipients when recipient policies were modified.
Because the RUS is not present in Exchange Server 2007, you need to
implement various processes to update recipients due to changes in
policies; this will be covered in the next section.
Although the RUS is not present
in Exchange Server 2010, you do need to provide RUS functionality in a
mixed environment for the duration of your migration. You also need to
understand the new recipient update process that occurs when your mailboxes are moved to Exchange Server 2010.
6.3.3. RUS Migration Considerations
In a mixed environment, removing
the RUS process from Exchange Server 2010 has implications. One issue
is that if you configure an existing RUS instance to use an Exchange
Server 2010 computer through the Exchange System Manager GUI, that RUS
instance will cease functioning. The RUS functionality must be
maintained on an Exchange Server 2003 computer until all mailboxes have
been moved to Exchange Server 2010, even for domains containing only
servers running Exchange Server 2010.
In addition, you should
examine your user-provisioning tools or processes during the Exchange
Server 2010 planning process. Some tools or processes designed for
Exchange Server 2003 may partially provision users expecting the RUS to
complete the provisioning process. Also, changes to E-mail
Address Policies in Exchange Server 2007 may have to be applied to
existing users because the RUS process no longer exists. Applying E-mail
Address Policy changes can easily be accomplished using the Update-EmailAddressPolicy and Update-AddressList PowerShell cmdlets. Run the Update-EmailAddressPolicy cmdlet first because it updates recipients based on the organization's E-mail Address Policies. The Update-AddressList cmdlet updates your address lists with changes to recipients, so you should run it after the Update-EmailAddressPolicy cmdlet; always run these two cmdlets together. You can combine them with their corresponding get cmdlets as follows, to update the entire organization in a single script:
Get-EmailAddressPolicy | Update-EmailAddressPolicy
Get-AddressList | Update-AddressList
You can also use this approach to update the Global Address Lists in your organization as follows:
Get-GlobalAddressList | Update-GlobalAddressList
